With the ever-increasing frequency of software product updates and the continually improving ease of patch distributions and applications, administrators increasingly find it difficult to keep a software product up-to-date with the large number of updates that are available. Unfortunately, existing patching techniques do not allow an administrator to apply multiple patches at the same time with unified progress and rollback in a single transaction. The updates may have any of the following properties: a series of updates for a single product, a single update that applies to multiple products, multiple updates that apply to different products, or a combination of the above. Under existing patching techniques, an administrator may chain together a series of updates for a single product. However, the existing patching techniques apply the updates one by one in multiple transactions—a time intensive operation. Additionally, an administrator may use the existing patching techniques to apply an update to multiple products installed on a machine. Each target product is patched in a separate transaction. Thus, a failure in the transaction will rollback the patching of the current target product and will terminate the process to update multiple products, which may leave one or more products un-patched. And the target products that were patched before the failure will remain updated. Accordingly, under the existing patching techniques, administrators may not effectively update multiple target products without losing productivity and do not have the ability to deliver a new application to an existing machine or an existing application to a new machine without managing multiple patching or installation transactions. Furthermore, if the original product has a security vulnerability, then the current patching techniques may leave the product in the vulnerable state until the different patches have been applied to the product.
Additionally, with the volume of available product updates, administrators find it increasingly difficult to manage the security of the machines in their environments. Even though administrators typically do not want their users to have administrative privileges, some product updates desire users to have administrative privileges to apply the updates. In addition, even though administrators may allow a non-privileged user to patch a software product by enabling a system-wide policy that permits patching of different software products on a system, security implications may prohibit the administrators from enabling this system-wide policy. More specifically, under current patching techniques, if a software product is installed with elevated privileges, then a non-privileged user may not be able to update the software product unless an administrator enables the system-wide policy. This system-wide policy equally applies to different user accounts and different patches and does not allow an administrator to individually enable a particular user account or a particular patch to update a software product. Thus, the current patching techniques do not allow a user to effectively apply a pre-approved patch to a software product without having the administrative privilege.
Further complicating the problem, products that desire administrative privileges for installation typically install files in locations to which non-administrative users do not have write access. This limitation does not function well in a home user environment or in a corporate environment. For example, in a home user environment, a software product may desire that a user to have the ability to run the product as a non-administrator. However, the software product that desires patches to run properly may update files in a location in which a non-administrator generally does not have write privileges. This is especially true for massive multi-user online games where users patch the games on their systems to match the version installed on a server. In a corporate environment, the existing patching techniques typically do not allow an administrator to grant a non-privileged user the privilege to install an update. Thus, the administrator may have to apply the update such that the update is included in the original installation. The client machine would then have to be re-synchronized with the patched image to obtain the update. Thus, current patching techniques do not provide an effective way for non-privileged clients to patch a software product without compromising system security.
Accordingly, a solution that effectively applies multiple patches to one or more software products in a single transaction and allows a non-privileged user to apply a patch to a software product is desired.